As Scrum trainer I am always trying to get my mind around what makes a particular Scrummaster click, and how can I get across scrum concept such as values, philosophy and practices, so he/she can enable their teams to do well in Scrum.
What is in your Product Backlog?
Unlike the “what is in your wallet” ad, in Scrum we place all work we need to deliver a product within a prioritized list called a Product Backlog. The Product Backlog is made of items that represent something to be built, and these items can be classified depending on their size as an Epic, Feature, or Story.
Epics represent huge requests that you can not figure how to build without understanding what the customer means, as an example “Build a corporate website”. Features are smaller in size to Epics, and you need a lot of Features to build an Epic. There is one specific Feature that is important to note and that is the “Backbone feature“, which usually gets built first. And as you have guessed already, Features like Epics are too large to plan with, so they need to be split into smaller size chunks of work called a Story. Tasks are the smallest artifacts in Scrum, and includes the “what”, “who” and “how” actions needed to single story.
I am hungry what is the story behind the Slicing and Dicing?
It is all about the slicing and dicing when it comes to Scrum and having a healthy product backlog. By healthy I mean that if a team expects to deliver a “potentially demonstrable” piece of functionality at the end of a sprint, then it is the skill of slicing and dicing features that we need to focus on.
After working with many teams in different companies, I noticed that most of the times teams slice and dice from a feature to a story along technology lines. For example they would split a story to “build a form” into something along these lines:
Creating stories that are sliced along technology lines are prone to queuing and having to wait for one story to finish so the other can start, it extends the time for Product Owners and Stakeholders to see the demonstrable functionality, hence adds risk to the project and the delivery time.
Well this brings us back to the concept of “Sashimi” in Scrum, and the importance for Scrum masters to master this concept and help teams to dice the stories sashimi style. Sashimi style of stories are sliced along functionality instead of technology. Each sprint, an increment of the work includes more functionality to complete the story. This gradual building of the feature through stories reduces risks, surfaces issues in the design, requirements or misunderstandings early on in the process.
Sashimi stories are great for daily scrum meetings, as a team you would know when it is done, and you can get better at it as you go. A technology story may be optimized to be done in 1.5 seconds, but the product is neither demonstrable nor does it guarantee that the finished product will work. It is the “inspectable” property of sashimi stories that drive Agile development forward.
One of my favorite things to tell my students is that “Product Increment is what Sashimi is to Tuna“, and that seems to get stuck in people’s mind long enough to pass it along to their team mates and produce that juicy slice of Sashimi.
Conclusion
Practice slicing stories along demonstrable functionality (Sashimi style) versus technology slices that are not. Keep track of the assumptions you made to make your sashimi work, and add them as upcoming stories. Populate your product backlog with thinly sliced sashimis that will make the done criteria easier to achieve and understand, better reviews, and better two-way communications between the team and stakeholders.